Method for controlling a multi party call and a service control entity and a service switching entity for performing the method

ABSTRACT

The invention relates to a method for controlling a multi party call between three or more communication entities within a communications network. The communications network comprise a service control entity and a service switching entity. The service control entity performs: a) receiving a notification of a multi party event associated with the multi party call from the service switching entity, b) determining a procedure for handling the multi party event, c) transmitting instructions to the service switching entity in accordance with the procedure for handling the multi parry event.

TECHNICAL FIELD

The invention relates to a method for controlling a multi party callbetween three or more communication entities within a communicationsnetwork, a service control entity adapted to perform the method and aservice switching entity adapted to perform the method. The inventionfurther relates to a computer program loadable into a processing unit ofsuch a service control entity or service switching entity and acomputer-readable medium product comprising such a computer program.

BACKGROUND

A network may be provided enabling communication entities to communicatewith each other. The communication entities may be wireline telephones,mobile telephones or any other suitable device. The communicationentities that initiate communication may be referred to as callingentities and the communication entities with which the calling partiesinitiate communication are referred to as remote entities or calledentities.

In the telecommunications network a call initiated by a calling entityand destined for a remote entity is routed through a number of switchingnodes before this call reaches its destination. An example of how a callmay be routed from a calling entity to a remote entity in atelecommunications network is given with reference to FIG. 1. A callingentity CE-A sets up a call to a called entity CE-B by sending a call setup request message to a switching node 101. The switching node 101receives the call set up request message and analyses the destinationnumber comprised therein, i.e. typically a number associated to calledentity CE-B. Depending on the outcome of the analysis the switching node101 will select the most appropriate next switching node for routing thecall further in the most efficient way. In this example the switchingnode 101 selects a switching node 102. Switching nodes 102 and 103behave in a similar way and route the call further towards switchingnode 104, which is closest to the called entity CE-B. Switching nodes102 and 103 are sometimes also referred to as transit switching nodes,because they function as transits between switching nodes 101 and 104.The switching node 104 then connects the incoming call to called entityCE-B and a speech connection may be opened between calling entity CE-Aand called entity CE-B.

According to the Intelligent Network (IN) concept, service intelligenceor service logic is separated from switching functions. This separationenables network operators to develop and deploy services and featuresindependently of network vendors, allowing more flexibility in servicedevelopment, simplified rollout, reduced cost and greater autonomy.Examples of IN protocols are the Intelligent Network ApplicationProtocol (INAP), the Advanced IN (AIN), and the Customized Applicationsfor Mobile network Enhanced Logic (CAMEL). INAP was developed for fixedline networks and is the primary protocol used for fixed line IN outsideof North America. AIN is a variant developed for North America.

CAMEL

CAMEL is a Global System for Mobile communications (GSM) Phase 2+ andWideband Code Division Multiple Access (WCDMA) network feature specifiedin 3GPP TS 22.078. CAMEL is based on core INAP with modifications totake into account, amongst others, subscriber mobility. In particular,CAMEL enables the use of operator-specific services by a subscriber evenwhen roaming outside the subscriber's Home Public Land Mobile Network(PLMN). A CAMEL-based Intelligent Network comprises as main entities aservice switching entity for switching tasks, also referred to as SSF(Service Switching Function) or gsmSSF (GSM Service Switching Function)and a service control entity comprising the service intelligence orlogic also referred to as SCF (Service Control Function) or gsmSCF (GSMService Control Function).

FIG. 2 depicts a schematic overview of a telecommunications networkcomprising an intelligent network.

The intelligent network comprises a service control entity SCE and aservice switching entity SSE, which will both be explained in moredetail below. Furthermore, switching nodes 203, 204 and 205 aredepicted, each of which may be a Mobile Services Switching Centre (MSC).The switching node 203 may function as an originating node; theswitching node 204 may be a transit switching node and the switchingnode 205 may be a terminating node.

Intelligent networks services are executed at the service control entitySCE. The service control entity SCE is able to communicate with theservice switching entity SSE using an intelligent network protocol suchas CAMEL or INAP. The service switching entity SSE, when controlling thecall from calling entity CE-A to called entity CE-B, is preferablyco-located with switching node 203, but may also be co-located atanother switching node.

The service control entity SCE has a leading role in the intelligentnetwork and may decide that some services are allowed or disallowed fora call. It sends instructions to the service switching entity SSE to becarried out by the service switching entity SSE.

With the application of the intelligent network concept, there areeffectively two levels of call control: (1) call control by theswitching node and (2) call control by the SCE. Because of the twolevels of control that are also separate from each other,inconsistencies may occur when an IN service is invoked for a call thatmay be in addition subject to a service executed at a switching node.This may be, for example, the case when a first communication entityCE-A sets up a multi party call. Prior to the establishment of the multiparty call, the first communication entity CE-A may be involved in twocalls, a first call with a second communication entity CE-B which isactive and on hold, and a second call with a third communication entityCE-C (explained below with reference to FIG. 6) which is active and inspeech connection. The first communication entity CE-A may then initiatea multi party call in which the two calls are merged (explained belowwith reference to FIG. 7).

Multi Party Service

Multi party service is a so-called supplementary service or networkbased service that is executed by and under the control of switchingnodes, such as MSCs. The multi party service provides a firstcommunication entity CE-A (calling or called entity) with the ability toestablish a multi-connection call, i.e. a simultaneous communicationwith a second and third communication entities. In fact, also more thenthree communication entities may be involved. The communication entityhaving established a multi party call may be referred to as “multi partyserved subscriber” or “multi party served entity”. It be emphasised thatwhen an entity establishes a multi party call, the respective calls thatare connected to or from this call entity may, independently of eachother, be incoming or outgoing. The communication entities thatparticipate in the multi party call but did not initiate the multi partycall are also referred to as remote communication entities.

For the GSM and the 3G network, the Multi party service is specified in3GPP technical specification 22.084.

For example, the multi party served entity CE-A is involved in twocalls; one active call in speech connection with second communicationentity CE-B and one active call on hold with third communication entityCE-C, both calls having been answered by the respective called secondand third communication entity CE-B, CE-C respectively. In thissituation the multi party served subscriber CE-A may request the networkto execute the multi party service.

Once a multi party call is established, additional communicationentities may be added to the multi party call, disconnected from themulti party call, temporarily separated (i.e. removed) from the multiparty call and, when temporarily separated, reconnected to the multiparty call.

Subscribers or communication entities participating to a multi partycall may be referred to as conferee.

An acknowledgement is sent towards the multi party served subscriberCE-A at the invocation of this supplementary service while anotification is sent towards all the remote parties in a multi partycall. The multi party call will, just after it has been established, beconstituted just by three parties, that is the multi party servedsubscriber (first communication entity CE-A) and the other twosubscribers (second and third communication entity CE-B and CE-C) thattill the moment of invocation were engaged in two separated calls withthe multi party served subscriber (first communication entity CE-A). Atthis stage other communication entities (fourth, fifth etc.) can beincluded in the multi party call if the multi party served subscriberdecides hereto. A notification may be sent towards all remotecommunication entities, i.e. second, third etc. communication entities(i.e. not towards the multi party served subscriber CE-A) every time anew communication entity is added to the multi party call. Notificationsmay also be sent to remote communication entities when they are put onhold and when they are retrieved; these notifications related to holdand retrieve are in accordance with normal Call Hold procedures.

The multi party service as stated before, is a network based servicethat is executed by and under control of switching nodes, whereas INservices are executed under the control of a service control entity andinvoked for certain calls only. Because of the two levels of controlthat are also separate from each other, inconsistencies may occur whenan IN service is invoked for a call that may be in addition subject to amulti party service executed at a switching node.

It is an object to provide a solution to improve the handling of a multiparty call in a telecommunications network.

SUMMARY

According to an embodiment, a method is provided for controlling a multiparty call between three or more communication entities within acommunications network. The communications network comprises a servicecontrol entity and a service switching entity. The service controlentity may perform:

a) receiving a notification of a multi party event associated with themulti party call from the service switching entity,

b) determining a procedure for handling the multi party event,

c) transmitting instructions to the service switching entity inaccordance with the procedure for handling the multi party event.

According to a further embodiment, the method further comprisesrequesting the service switching entity to send a notification of anindicated multi party event.

The notification of the multi party event may comprise a request fromone of the three or more communication entities for setting up the multiparty call. The instructions for handling the multi party event comprisea permission indicator indicating whether or not the multi party call isallowed.

Action b) may comprise applying service logic.

The notification of the multi party event may comprise an indication ofat least one communication entity associated to the multi party event.

Action b) may further comprise applying service logic in combinationwith the indication of the at least one communication entity associatedto the multi party event.

The multi party event comprises one of

-   -   Conference Established (66),    -   Conference Disconnected (67),    -   Other Party Added (68),    -   Isolated (69),    -   Reattached (70),    -   Other Party Isolated (71),    -   Other Party Reattached (72),    -   Other Party Split (73),    -   Other Party Disconnected (74),    -   Conference Floating (75).

Furthermore there is provided a service control entity adapted toperform the method according to the above.

According to a further embodiment there is provided a method forcontrolling a multi party call between three or more communicationentities within a communications network. The communications networkcomprises a service control entity and a service switching entity. Theservice control entity may perform:

a) receiving a notification of a multi party event associated with themulti party call

b) sending the notification to the service control entity,

c) receiving instructions from the service control entity in accordancewith a procedure for handling the multi party event, and

d) processing the multi party event in accordance with the receivedinstructions.

According to an embodiment, the method may further comprise receiving arequest from the service control entity to send a notification of anindicated multi party event.

The notification of the multi party event may comprise a request fromone of the three or more communication entities for setting up the multiparty call. The instructions for handling the multi party event maycomprise a permission indicator indicating whether or not the multiparty call is allowed.

Action d) may comprise disallowing or allowing the multi party event inaccordance with the permission indicator.

The notification of the multi party event may comprise an indication ofat least one communication entity associated to the multi party event.

The multi party event may comprise one of

-   -   Conference Established (66),    -   Conference Disconnected (67),    -   Other Party Added (68),    -   Isolated (69),    -   Reattached (70),    -   Other Party Isolated (71),    -   Other Party Reattached (72),    -   Other Party Split (73),    -   Other Party Disconnected (74),    -   Conference Floating (75).

According to an embodiment there is provided a service switching entityadapted to perform the method according to above.

According to an embodiment there is provided a computer program loadableinto a processing unit of a service control entity or a serviceswitching entity, the computer program comprising portions of softwarecode adapted to perform any one of the methods according to the above.

Furthermore, according to an embodiment there is provided acomputer-readable medium product comprising a computer program accordingto the above.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will now be described, by way of example only, withreference to the accompanying schematic drawings in which correspondingreference symbols indicate corresponding parts, and in which:

FIG. 1 shows a first schematic illustration of a telecommunicationsnetwork for routing of a call according to the prior art,

FIG. 2 shows a schematic illustration of a telecommunications networkaccording to an embodiment of the invention,

FIG. 3 shows a schematic illustration of a general computer,

FIG. 4 shows a block diagram of an embodiment of a service controlentity,

FIG. 5 shows a block diagram of an embodiment of a service switchingentity.

FIG. 6 shows network architecture for a first communication entityhaving two calls established, prior to the establishment of a multiparty call,

FIG. 7 shows network architecture for a first communication entityhaving two calls established, after the establishment of a multi partycall,

FIG. 8 shows a flow diagram according to an embodiment,

FIG. 9 shows a flow diagram according to a further embodiment.

DETAILED DESCRIPTION

With reference to FIG. 2 an explanation is provided of a communicationsnetwork, comprising network elements such as a service switching entitySSE for switching tasks and a service control entity SCE comprising theservice intelligence or logic. Both the service control entity SCE andthe service switching entity SSE may be formed as computers, embodimentsof which are described below. Of course, also other network elements,such as switching nodes may be provided that are formed as computers asdescribed with reference to FIG. 3.

In fact, all network elements, including communication entities,described in the embodiments may be formed as a computer. FIG. 3schematically shows a general embodiment of an example of a computer.The description may refer to several kinds of devices, such as personalcomputers, servers, laptops, personal digital assistances (PDA),palmtops, telephones. All these devices may be different kind ofcomputers.

FIG. 3 shows a schematic block diagram of an embodiment of a computer10, comprising a processor unit PU for performing arithmeticaloperations. The processor unit PU is connected to memory ME that maystore instructions and data. The memory ME may be formed by one or moreof a tape unit, hard disk, Read Only Memory (ROM), Electrically ErasableProgrammable Read Only Memory (EEPROM) and Random Access Memory (RAM).The memory ME may comprise instructions that are readable and executableby the processor unit PU to enable the computer 10 to perform theembodiments described.

The processor unit PU may also be connected to one or more inputdevices, such as a keyboard KE, and one or more output devices, such asa display DI, and one or more reading units RU to read for instance afloppy, CD ROM's CR, a DVD.

The computer 10 shown in FIG. 3 also comprises an input output device(I/O) that is arranged to communicate with other computers (not shown)via a network, for instance the intelligent network. Of course, theinput output device (I/O) may also be formed as a separate input deviceI and output device O.

However, it should be understood that there may be provided more and/orother memory units, input devices and read devices known to personsskilled in the art. Moreover, one or more of them may be physicallylocated remote from the processor unit PU, if required. The processorunit PU is shown as one box, however, it may comprise several processorunits functioning in parallel or controlled by one main processor unitthat may be located remote from one another, as is known to personsskilled in the art.

It is observed that, although all connections in FIG. 3 are shown asphysical connections, one or more of these connections can be madewireless. They are only intended to show that “connected” units arearranged to communicate with one another in some way.

The computer 10 is shown as a computer, but can be any signal processingsystem with analogue and/or digital and/or software technology arrangedto perform the functions discussed here.

As described in the discussion of the background, a CAMEL-basedIntelligent Network comprises as main entities a service switchingentity SSE for switching tasks, also referred to as SSF (ServiceSwitching Function) or gsmSSF (GSM Service Switching Function) and aservice control entity SCE comprising the service intelligence or logicalso referred to as SCF (Service Control Function) or gsmSCF (GSMService Control Function). Both the service control entity SCE and theservice switching entity SSE may also be formed as computers,embodiments of which are described below.

Service Control Entity

FIG. 4 depicts an embodiment of a service control entity SCE comprisingan input device I4 for receiving messages and an output device O4 fortransmitting messages, a processor unit PU4 for processing messages andinformation and memory ME4 for storing and/or obtaining of information.

A service control entity SCE may be a stand alone device and inputdevice I4 and output device O4 being external interfaces like areceiving unit for receiving messages and a transmission unit fortransmitting messages, respectively. However, it is also conceivablethat a service control entity SCE is operating at a switching node, e.g.as a hardware and/or software sub-unit of the switching node. Theservice control entity SCE may be installed and operated at theswitching node sharing none of the units I4, O4, P4, ME4 with theswitching node or sharing at least one of the units I4, O4, P4, ME4 withunits of a switching node. An alternative embodiment is a servicecontrol entity SCE according to a computer program loaded into theprocessing unit of a switching node.

Service Switching Entity

FIG. 5 depicts an embodiment of a service switching entity SSEcomprising an input device I5 for receiving messages and an outputdevice O5 for transmitting messages, a processor unit PU5 for processingmessages and information, and memory ME5 for storing and/or obtaining ofinformation.

A service switching entity SSE may be a stand alone device and inputdevice I5 and output device O5 being external interfaces like areceiving unit for receiving messages and a transmission unit fortransmitting messages, respectively. Preferably, a service switchingentity SSE is operating at a switching node, e.g. as a hardware and/orsoftware sub-unit of the switching node. The service switching entitySSE may be installed and operated at the switching node sharing none ofthe units I5, O5, PU5, ME5 with the switching node or sharing at leastone of the units I5, O5, PU5, ME5 with units of a switching nodecomprising an input device for receiving messages, an output unit forsending messages, a processor unit for processing messages andinformation, and preferably a memory. According to an embodiment aservice switching entity SSE is provided according to a computer programloaded into the processor unit of a switching node.

A problem may occur when the CAMEL service allows the call to becomepart of a multi party call. If the first communication entity CE-Ainvokes a multi party service for this call, i.e. joins the call that isin speech connection with the second communication entity CE-A and theheld call with the third communication entity CE-C into the conferencecall, then the CAMEL service of the respective calls from thissubscriber will not be aware that the call has changed into a multiparty call. This is further explained with reference to FIGS. 6 and 7.

FIG. 6 depicts the situation before the first communication entity CE-Ainvokes a multi party call. Two originating calls have been started fromthe first communication entity CE-A: one call between the firstcommunication entity CE-A and the second communication entity CE-B andanother call between the first communication entity CE-A and the thirdcommunication entity CE-C. Two legs are created. The first leg comprisesswitching nodes 203-A (A-B), 204-B, 205-B and first service switchingentity SSE-AB.

The indication A-B in the text is used to indicate that it refers to theprocess for the connection between first communication entity CE-A andsecond communication entity CE-B. Likewise, the indication A-C as usedbelow is used to indicate that it refers to the process for theconnection between first communication entity CE-A and thirdcommunication entity CE-C. So, switching node 203-A (A-B) refers to theprocess in switching node 203 for the call from the first communicationentity CE-A to the second communication entity CE-B; likewise, switchingnode 203-A (A-C) refers to the process in switching node 203 for thecall from first communication entity CE-A to third communication entityCE-C.

The second leg comprises switching nodes 203-A (A-C), 204-C, 205-C andsecond service switching entity SSE-AC.

ISDN User Part (ISUP), Bearer Independent Call Control (BICC) or SIP-Isignalling is used between the respective switching nodes 203, 204 and205. The remainder of the present invention refers only to ISUP; theinformed reader will understand that BICC and SIP-I may be used as well,where applicable.

FIG. 7 depicts the situation after the first communication entity CE-Ahas invoked the multi party call service. Two instances of serviceswitching entities SSE are present in the call chain, the first serviceswitching entity SSE-AB and the second service switching entity SSE-AC.

The first service control entity SCE-AB could instruct the first serviceswitching entity SSE-AB to be informed of call events such as Callanswer or Call disconnect. However, the service control entities SCE-AB,SCE-AC would not know that a multi party call is established.

When the multi party call is established, the second and thirdcommunication entities CE-B and CE-C are put in conference and speechinformation from the first, second and third communication entitiesCE-A, CE-B and CE-C is routed through a conference device located in orcontrolled by switching node 203-A. Each communication entity in theconference call will receive the combined speech of the othercommunication entities in the conference call. From this moment on,whatever information (such as credit information) is sent on the speechchannel under control by a service control entity SCE towards onecommunication entity is heard also by the other communication entities.

After the conference call is established, one of the two service controlentities SCE-AB or SCE-AC might instruct the service switching entitySSE-A that it is connected to, i.e. SSE-AB or SSE-AC respectively, tosend in-band information (tone or announcement) towards the firstcommunication entity CE-A. This information would actually be heard alsoby one or more other communication entities CE-B, CE-C, for whom theinformation is not intended.

Furthermore, the identity of the second and third communication entitiesCE-B, CE-C participating to the multi party call will not be known tothe respective service control entities SCE. Hence, if a service controlentity SCE wants for example certain subscribers not to participate ininternational conference call, then the service control entity SCE isnot able to enforce this policy, since (a) the service control entitySCE does not know that a multi party call call is established and (b)the service control entity SCE does not know the identities of the allparticipants in the multi party call. For instance, the service controlentity SCE-AB only knows the identity of the first and secondcommunication entities for the respective call. It be emphasised againthat the call legs in a conference call are controlled by independentservice control entities SCE instances.

According to ITU-T recommendation Q.734, when an MSC wishes to notify aremote party of a multi party invocation on the part of a served user,an ISUP Call Progress (CPG) message is used with the ‘GenericNotification’ parameter that may contain the following indications:

-   -   Conference established,    -   Conference disconnected,    -   Other party added,    -   Isolated,    -   Reattached,    -   Other party isolated    -   Other party reattached,    -   Other party split,    -   Other party disconnected,    -   Conference floating.

The ISUP CPG message does not have the capability to convey the numberof the conferee to which the multi party event, as indicated in the ISUPCPG, applies.

Embodiments

Below, several embodiments are provided that overcome the abovementioned drawbacks.

Service Control Entity

According to an embodiment there is provided a method as shown in FIG.8. The method may be performed by the service control entity SCE forcontrolling a multi party call between three or more communicationentities within a communications network, the communications networkcomprising a service control entity and a service switching entity,wherein the service control entity performs:

a) receiving a notification of a multi party event associated with themulti party call from the service switching entity (action 901),

b) determining a procedure for handling the multi party event (action902),

c) transmitting instructions to the service switching entity inaccordance with the procedure for handling the multi party event (action903).

According to an embodiment, the method further comprises requesting theservice switching entity to send a notification of an indicated multiparty event. This may be done before action 901, to instruct the serviceswitching entity SSE such that a notification of a specific multi partyevent is received in action 901. This enables the service control entitySCE to receive only notifications of those multi party events in whichit is interested and hence leads to greater flexibility for the servicecontrol entity SCE when controlling the multi party call. For example,the service control entity SCE may indicate to the service switchingentity SSE that it is only interested to receive an indication of thefollowing multi party events: conference established, other party added,other party disconnected. As a result, the service control entity SCEdoes not receive a notification of any of the other multi party events

According to an embodiment, the notification of the multi party eventcomprises a request from one of the three or more communication entitiesCE-A, CE-B, CE-C for setting up the multi party call and theinstructions for handling the multi party event comprise a permissionindicator indicating whether or not the multi party call is allowed.Based on the permission indicator the service switching entity candecide whether or not to allow the setting up of the multi party event.

According to an embodiment action 902 comprises applying service logic.

According to an embodiment, the notification of the multi party eventcomprises an indication of at least one communication entity CE-A, CE-B,CE-C associated to the multi party event. The service control entity SCEis now informed of the identity of the communication entities involvedin the multi party call and is enabled to take further action based onthis information.

According to an embodiment, the b) (action 902) further comprisesapplying service logic in combination with the indication of the atleast one communication entity associated to the multi party event. Thisindication of the at least one communication entity CE-A, CE-B, CE-C canbe used when applying the service logic to decide on the appropriateprocedure. For instance, if the second communication entity CE-B is anforeign communication entity compared to the first communication entityCE-A, and the service logic doesn't allow this, the procedure may be toabort the request for setting up the multi party call.

The multi party events may be one of

-   -   Conference Established (66),    -   Conference Disconnected (67),    -   Other Party Added (68),    -   Isolated (69),    -   Reattached (70),    -   Other Party Isolated (71),    -   Other Party Reattached (72),    -   Other Party Split (73),    -   Other Party Disconnected (74),    -   Conference Floating (75).

An embodiment of a service control entity SCE as shown in FIG. 4 isprovided that is arranged to perform the method as described withreference to FIG. 8.

A service control entity SCE may be provided as shown in FIG. 4, forperforming a method for controlling a multi party call between three ormore communication entities within a communications network, thecommunications network comprising a service control entity and a serviceswitching entity.

The service control entity SCE comprises an input device I4 forreceiving messages and an output device O4 for transmitting messages, aprocessor unit PU4 for processing messages and information and memoryME4 for storing and/or obtaining of information.

The processor unit PU4 may be adapted to process a notification of amulti party event associated with the multi party call received viainput device I4 from the service switching entity (action 901).

Also, the processing unit PU4 may be adapted to determine a procedurefor handling the multi party event (action 902).

Furthermore, the processing unit PU4 may be adapted to initiate thetransmission via the output device O4 of instructions to the serviceswitching entity SSE in accordance with the procedure for handling themulti party event (action 903).

According to an embodiment there is provided a computer program loadableinto a processing unit of a service control entity SCE, the computerprogram comprising portions of software code adapted to perform themethod as described with reference to FIG. 7. The computer program maybe comprised by a computer-readable medium.

According to a further embodiment there is provided a computer programloadable into a processing unit PU4 of a service control entity SCE, thecomputer program comprising portions of software code adapted to performthe method as described above with reference to FIG. 8.

According to a further embodiment there is provided a computer-readablemedium product comprising such a computer program.

Service Switching Entity

According to an embodiment, there is provided a method as shown in FIG.9. The method may be performed by a service switching entity SSE forcontrolling a multi party call between three or more communicationentities within a communications network, the communications networkcomprising a service control entity and a service switching entity,wherein the service control entity performs:

a) receiving a notification of a multi party event associated with themulti party call (action 910),

b) sending the notification to the service control entity (action 911),

c) receiving instructions from the service control entity in accordancewith a procedure for handling the multi party event (action 912), and

d) processing the multi party event in accordance with the receivedinstructions (action 913).

According to an embodiment the method further comprises receiving arequest from the service control entity to send a notification of anindicated multi party event.

According to an embodiment the notification of the multi party eventcomprises a request from one of the three or more communication entitiesfor setting up the multi party call and wherein the instructions forhandling the multi party event comprise a permission indicatorindicating whether or not the multi party call is allowed.

According to an embodiment, the notification of the multi party eventcomprises an indication of at least one communication entity associatedto the multi party event.

According to an embodiment d) (action 913) comprises disallowing orallowing the multi party event in accordance with the permissionindicator.

According to an embodiment, the multi party event comprises one of

-   -   Conference Established (66),    -   Conference Disconnected (67),    -   Other Party Added (68),    -   Isolated (69),    -   Reattached (70),    -   Other Party Isolated (71),    -   Other Party Reattached (72),    -   Other Party Split (73),    -   Other Party Disconnected (74),    -   Conference Floating (75).

An embodiment of a service switching entity SSE as shown in FIG. 5 isprovided that is arranged to perform the method as described withreference to FIG. 9.

A service switching entity SSE may be provided as shown in FIG. 5, forperforming a method for controlling a multi party call between three ormore communication entities within a communications network, thecommunications network comprising a service switching entity SSE and aservice switching entity SCE. The service switching entity SSE comprisesan input device I5 for receiving messages and an output device O5 fortransmitting messages, a processor unit PU5 for processing messages andinformation and memory ME5 for storing and/or obtaining of information.

The processor unit PU4 may be adapted to process a notification of amulti party event associated with the multi party call received viainput device I4 (action 910).

The processor unit PU4 may be adapted to initiate the sending via outputdevice O4 of the notification to the service control entity (action911).

The processor unit PU4 may be adapted to process instructions receivedvia input device I4 from the service control entity in accordance with aprocedure for handling the multi party event (action 912).

Finally, the processor unit PU4 may be adapted to process the multiparty event in accordance with the received instructions (action 913).

According to a further embodiment there is provided a computer programloadable into a processing unit PU5 of a service switching entity SSE,the computer program comprising portions of software code adapted toperform the method as described above with reference to FIG. 9.

According to a further embodiment there is provided a computer-readablemedium product comprising such a computer program.

IN protocols like INAP and CAMEL Application Part (CAP, e.g. CAPv4, see3GPP TS 29.078 and 3GPP TS 23.078) are preferably amended by at leastone of the following detailed enhancements to provide a serviceswitching entity SSE and a service control entity SCE with thecapabilities according to the invention:

-   a) A new Event Detection Point (EDP), ‘multi party event’, may be    defined to indicate that a multi party event has occurred in the    call from the CAMEL subscriber. This EDP is defined for both the    Originating basic call state model (O-BCSM) and the Terminating    basic call state model (T-BCSM).    -   The call leg on which the event will be reported will be the leg        in the service switching entity SSE that receives the ISUP Call        Progress (CPG) message carrying the notification of the        occurrence of the MPTY event.-   b) A new BCSM event may be added to the Request Report BCSM (RRB)    message from the service control entity SCE to the service switching    entity SSE to arm the new EDP multi party event. The service control    entity SCE may use the Request Report BCSM message comprising the    new BCSM event to request the service switching entity SSE to send a    notification of an indicated multi party event.-   c) A new BCSM event may be added to the Event Report BCSM (ERB)    message from the service switching entity SSE to the service control    entity SCE to report the new EDP multi party event to the service    control entity SCE. The service switching entity SSE may use the    Event Report BCSM message comprising the new BCSM event to send the    notification of the multi party event to the service control entity    SCE.-   d) In the Event Report BCSM (ERB) message the parameter “Detection    Point (DP) specific info” may be enhanced with the capability to    convey an indication, i.e. a directory number, of the communication    entity associated to the multi party event, e.g. the communication    entity that is added, isolated, reattached. The indication may be    referred to as conferee number. The service switching entity may use    the Event Report BCSM comprising the enhanced parameter to send the    notification of the multi party event comprising an indication of at    least one communication entity associated to the multi party event    to the service control entity SCE.

Furthermore also the ISUP protocol is preferably amended by thefollowing enhancement to provide a service switching entity and aservice control entity with the capabilities according to the invention.

-   -   a) The ISUP Call Progress (CPG) message may be enhanced to        carry, in addition to the multiparty event notification, the        conferee number of the communication entity associated to the        multi party event.

Advantages

According to the prior art, when the first entity CE-A requests toestablish a multi party call, this request is processed and executed bythe switching nodes 203 and (to a lesser extent) by the switching nodes204 and 205. This may cause problems and unwanted situations, as theservice control entity SCE will not know that the first communicationentity CE-A has initiated the establishment of a multi party call. Forinstance, the service control entity SCE may need to verify whether thefirst communication entity CE-A has permission to start a multi partycall and if so, whether the first communication entity CE-A haspermission to set up a multi party call with the particular second andthird communication entities CE-B and CE-C. The first communicationentity CE-A may for instance not be allowed to set up an internationalmulti party call. Also, the SCE may want to restrict the number ofparticipants to a defined maximum.

An additional problem, resulting from the fact that the service controlentity SCE is not aware of the establishment of a multi party call, isthat the service control entity SCE could instruct the service switchingentity SSE to send in-band information (e.g. an announcement) to asubscriber without knowing that the in-band information may also beheard by other parties in the call.

According to the embodiments, this drawback is overcome by making theservice control entity SCE aware of the establishment of the multi partycall.

The service control entity SCE will get informed about multi partyevents such as multi party invocation and new connected subscribersidentity, so is enabled to act accordingly. This facilitates the SCE topermit, at call establishment, the establishment of a multi party callduring that call. When a multi party call is established during thatcall, then the SCE will be informed hereof and may determine whether themulti party call is allowed, considering e.g. the directory numbers ofthe parties involved in the multi party call. The SCE may applydifferent decision criteria to determine whether a multi party isallowed. E.g. a subscriber is not entitled to establish a multi partycall involving international conferees.

The service control entity SCE will get informed of the specificoperation performed inside the multi party call (split, adding etc.).This will allow the service control entity SCE to know at each time whois receiving information (speech/data) for the call. This, inparticular, will allow the service control entity SCE to be aware of whowill listen to a tone or announcement when it decides to send such toneor announcement.

It is apparent that the invention may be implemented in anytelecommunication network like a GSM, Code Division Multiple Access(CDMA), Time Division Multiple Access (TDMA), Universal MobileTelecommunication System (UMTS), or 4G network. A service control entityis typically embodied in a single device or may be distributed overseveral devices. The corresponding applies to a service switchingentity. A service control entity and a service switching entity may beimplemented as separate functions on the same device or platform.

Also provided is a computer program loadable into a processing unit of aservice control entity, where the computer program comprises portions ofsoftware code adapted to perform at least one of the embodiments andmethods described above.

Also provided is a computer program loadable into a processing unit of aservice switching entity, where the computer program comprises portionsof software code adapted to perform at least one of the embodiments andmethods described above.

Also provided is a computer-readable medium product comprising at leastone of the computer programs as described above.

The descriptions above are intended to be illustrative, not limiting.Thus, it will be apparent to one skilled in the art that modificationsmay be made to the invention as described without departing from thescope of the claims set out below.

1. A method for controlling a multi party call between three or morecommunication entities within a communications network, wherein themulti party call is established using a plurality of call legs, whereineach call leg connects a call-originating communication entity with arespective call-participating communication entity in the multi-partycall, wherein the communications network comprises a service controlentity (SCE) and a service switching entity (SSE), wherein multipleinstances of the SCE and multiple instances of the SSE are present inthe communications network, wherein each pair of SCE-SSE instances isassociated with a corresponding one of the plurality of call legs, andwherein the SCE performs the steps of: a) receiving a notification of amulti party event associated with the multi party call from one of theSSE instances; wherein the notification is received at one of the SCEinstances that corresponds to the notification-sending SSE instance; b)obtaining from the SSE, identities of all communication entitiesinvolved in the multi party call by receiving, for each call leg,identities of all communication entities in that call leg, wherein callleg-specific identities in each call leg are received at a callleg-specific SCE instance from a corresponding call leg-specific SSEinstance; c) determining a procedure for handling the multi party event;and d) transmitting instructions to the SSE in accordance with theprocedure for handling the multi party event.
 2. The method according toclaim 1, further comprising requesting the SSE to send the notificationof an indicated multi party event.
 3. The method according to claim 1,wherein the notification of the multi party event comprises a requestfrom one of the three or more communication entities for setting up themulti party call and the instructions for handling the multi party eventcomprise a permission indicator indicating whether or not the multiparty call is allowed.
 4. The method according to claim 1, wherein thestep of determining a procedure for handling the multi party eventcomprises applying service logic.
 5. The method according to claim 4,wherein the step of determining a procedure for handling the multi partyevent further comprises applying service logic in combination with theidentity of at least one communication entity associated with the multiparty event.
 6. The method according to claim 1, wherein the multi partyevent comprises one of: Conference Established, Conference Disconnected,Other Party Added, Isolated, Reattached, Other Party Isolated, OtherParty Reattached, Other Party Split, Other Party Disconnected, andConference Floating.
 7. A service control entity (SCE) for controlling amulti party call between three or more communication entities within acommunications network, wherein the multi party call is establishedusing a plurality of call legs, wherein each call leg connects acall-originating communication entity with a respectivecall-participating communication entity in the multi-party call, whereinthe communications network further comprises a service switching entity(SSE), wherein multiple instances of the SCE and multiple instances ofthe SSE are present in the communications network, wherein each pair ofSCE-SSE instances is associated with a corresponding one of theplurality of call legs, and wherein the SCE comprises: a memory forstoring information; an input device for receiving a notification of amulti party event associated with the multi party call from one of theSSE instances, wherein the notification is received at one of the SCEinstances that corresponds to the notification-sending SSE instance; theinput device for further receiving, for each call leg, identities of allcommunication entities in that call leg, wherein call leg-specificidentities in each call leg are received at a call leg-specific SCEinstance from a corresponding call leg-specific SSE instance; an outputdevice for sending instructions to the SSE; and a processing unit forprocessing the notification of the multi party event and identities of acommunication entities associated with the multi party call, determininga procedure for handling the multi party event, and transmittinginstructions via the output device to the SSE in accordance with theprocedure for handling the multi party event.
 8. A method forcontrolling a multi party call between three or more communicationentities within a communications network, wherein the multi party callis established using a plurality of call legs, wherein each call legconnects a call-originating communication entity with a respectivecall-participating communication entity in the multi-party call, whereinthe communications network comprises a service control entity (SCE) anda service switching entity (SSE), wherein multiple instances of the SCEand multiple instances of the SSE are present in the communicationsnetwork wherein each air of SCE-SSE instances is associated with acorresponding one of the plurality of call legs, and wherein the SSEperforms the steps of: a) receiving a notification of a multi partyevent associated with the multi party call at one of the SSE instances;b) sending the notification to one of the SCE instances that correspondsto the notification-receiving SSE instance; c) providing identities ofall communication entities involved in the multi party call to the SCEby sending, for each call leg, identities of all communication entitiesin that call leg, wherein call leg-specific identities in each call legare sent from a call leg-specific SSE instance to a corresponding callleg-specific SCE instance; d) receiving instructions from the SCE inaccordance with a procedure for handling the multi party event, and e)processing the multi party event in accordance with the receivedinstructions.
 9. The method according to claim 8, further comprising theSSE receiving a request from the service control entity to send thenotification of an indicated multi party event.
 10. The method accordingto claim 8, wherein the notification of the multi party event comprisesa request from one of the three or more communication entities forsetting up the multi party call and the instructions for handling themulti party event comprise a permission indicator indicating whether ornot the multi party call is allowed.
 11. The method according to claim10, wherein step e) comprises disallowing or allowing the multi partyevent in accordance with the permission indicator.
 12. The methodaccording to claim 8, wherein the multi party event comprises one of:Conference Established, Conference Disconnected, Other Party Added,Isolated, Reattached, Other Party Isolated, Other Party Reattached,Other Party Split, Other Party Disconnected, and Conference Floating.